It looks like we have a chain reaction, since this article is a reaction to SunmaN's article from Hugi#20 about 4K intros for Win32, which also was a reaction to a reaction. *grin*

Usually we face the fact that our Win32 programs are enormous. Today it is not a problem to write a small 4096-byte "Hello, world!" program for Win32; which may surprise many Visual Basic programmers. However, 4096 bytes for a program that doesn't do anything is TOO MUCH !

Tools won't help, that available.
There's no linker that is able
to make an executable
with a size that's reasonable.

This little "poem" illustrates one thing, known from the very beginning: when you want to have something done good - do it yourself.

To create a small windows executable, we first have to learn the Windows executable format, which is know as Portable Executable (PE). Naturally, the portability of this format is questionable. We don't have too many resources:

- The description of the PE format, released before the first Win32, contains some useful information, though it is not sufficient. You can find it at wotsit.org.

- A very well known file named winnt.h, distributed with every C(++) compiler for Win32, contains the structures found in the PE headers, with a minimal description. Just use your favourite editor's search command and look for text "image format".

- Also the issue #2 of Assembly Journal (asmjournal.freeservers.com) contains an interesting article about a tiny PE executable.

Having these three resources we are able to create our own executable that will be very small. The article in asmjournal shows a Win32 console program that prints its command line. The program has only 192 bytes!!!! Unfortunately this is only possible under WinNT4. The app works under Win2K, but since it calls some kernel routines by their fixed WinNT4-specific addresses, it crashes.

So here we notice once again that WinNT is a very different OS from the so-called consumer Windows. WinNT is much less restrictive than Win9x, concerning the executables. Nevertheless we want to create small executables that will work with Win9x, too!

Choosing an assembler

At this point we choose an assembler - it will be NASM (the Netwide Assembler). This assembler allows us to hand-code a PE header with a minimal effort, using only one directive and no linker.

If you haven't used NASM, it is worth to know that it has two (and ONLY two) uncomfortable limitations. The following 32-bit code:

	jmp	here
here:	add	ecx, 5

...it assembles to these bytes:

E9 00 00 00 00   	   jmp	   +00000000h
81 C1 05 00 00 00	   add	   ecx, 00000005h

To make NASM behave kindly, we have to code:

	jmp	short here
here:	add	ecx, byte 5

...and then we get:

EB 00   		   jmp	   +00h
83 C1 05		   add	   ecx, +05h

As a side note, NASM has multiple advantages:

- it is free,

- it is simple as it has very, very few directives,

- it has a powerful preprocessor, not found in any other assembler,

- it provides you with total control over your code,

- it is extremely portable - you can use your code on any x86 OS.

But we aren't here to talk about NASM pros and cons... *grin*

First things first

How a PE executable works? A PE executable, further referred to as PE, consists of headers and sections. Headers contain data for the executable loader, and sections contain the actual program.

In the file, the sections of a PE are aligned. This means that each section starts at an address divisible by a number which is the base of the alignment, and also each section has a size divisible by that number. If it happens that a section is too short, i.e. its size is not aligned, it is simply padded with zeroes to the alignment boundary. For example if the required alignment is 32, and our section has only 24 bytes, additional 8 zeroes are added to the end of the section. The same goes for the headers: if the headers in our PE are too short, they are zero padded to the alignment boundary, so that the first section that follows them is aligned.

The docs say that all sections have to be aligned, but practice shows that the last section in a PE doesn't have to have aligned size - therefore file size doesn't have to be aligned.

Win9x requires that file alignment be 512 bytes (200h). This means that all the headers together occupy no less than 512 bytes, or a multiple of 512, and also every section, but the last one, occupies a multiple of 512 bytes. And here we have the first difference between WinNT and Win9x: WinNT doesn't have this restriction.

PE sections contain miscellaneous things. They may contain code, data, imports (references to functions imported from other DLLs), exports, resources, symbol tables, etc. No matter what the docs say and how the available linkers behave, it is not required that these entities reside in separate sections. For example, one can put code and data into one section. One can even put everything into one section - and this is what we want to do. As you may easily guess, doing this we gain a few bytes otherwise lost on file alignment.

Somewhere in the PE headers (later about where exactly) there is a number that tells where the PE will be loaded. A PE can be either a program or a DLL library (a DLL can be a library with routines, fonts, drivers, etc.). For DLLs this load address is only a proposed location - the system can load a DLL at a different location. But executables are (almost) always loaded at this address. And for executables this address is usually 400000h (4MB); using a different address than 400000h we risk our program being loaded not at the address we want. This fixed nature of a program's load address shows another difference between programs and DLLs - DLLs need additional relocation tables that will enable the system to relocate DLL code to a different location than the one specified, and executables usually don't have the relocations.

I am not going to explain the mysteries of 32-bit flat addressing mode here, but it is enough to know that each program has its own address space in this mode; as you are likely to know Win32 uses flat mode. A program calls multiple routines that reside in DLLs. These DLLs are mapped to the program's address space, and each DLL has a unique location - hence the need for relocating DLLs, while the program can have a fixed load address. Each module has a unique module handle, which sometimes needs to be passed to system functions, like CreateWindowEx() for example. As a matter of fact, this module handle is module load address; programs needlessly call the GetModuleHandle() routine, which always returns their load address, which is usually 400000h. Hence another optimisation for us: we won't ever need to import and call the GetModuleHandle() function.

PEs aren't loaded linearly. The headers are loaded exactly at the load address, but sections are further relocated. When being loaded, sections are expanded and aligned to a greater value than file alignment. This is called section alignment. The following table presents a set of entities residing in an example PE, and how they get relocated.

WNDCLASS WindowClass; // = { ... };

void main() // NOT WinMain()
{
   RegisterClass( &WindowClass );
   HWND hWnd = CreateWindowEx( 0, &ClassName, &ClassName,
		  WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, 0,
		  CW_USEDEFAULT, 0, 0, 0, 0x400000, 0 );
   ShowWindow( hWnd );
   UpdateWindow( hWnd );
   LPDIRECTDRAW lpDD;
   DirectDrawCreate( 0, &lpDD, 0 );
   lpDD->Vtbl->SetCooperativeLevel( lpDD, hWnd,
		  DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN );
   if ( lpDD->Vtbl->SetDisplayMode( lpDD, 640, 480, 32 ) )
      for (;;) {
	 WaitMessage(); // Replace this with your frame rendering
	 MSG msg;
	 if ( ! PeekMessage( &msg, 0, 0, 0, PM_REMOVE ) )
	    continue;
	 if ( msg.message == WM_QUIT )
	    break;
	 DefWindowProc( msg.hwnd, msg.message,
			msg.wParam, msg.lParam );
      }
   lpDD->Vtbl->Release( lpDD );
}

LRESULT CALLBACK WndProc ( HWND hwnd, UINT uMsg,
			   WPARAM wParam, LPARAM lParam )
{
   if ( uMsg != WM_DESTROY )
      goto DefWindowProc;
   PostQuitMessage( 0 );
}

   if ( msg.message == WM_KEYDOWN &&
	msg.wParam == VK_ESCAPE )
      CloseWindow( msg.hwnd );

lpDD->SetDisplayMode( 640, 480, 32 ); // In C++
lpDD->Vtbl->SetDisplayMode( lpDD, 640, 480, 32 ); // In C

(*lpDD)->SetDisplayMode( lpDD, 640, 480, 32 );